SMB 2.1 and subsequent versions of SMB have leasing mechanisms to improve coherency management between different clients and server. For example, a lease may be identified by a Lease Key and Client GUID (global unique identifier). When a client is trying to access a file it may request for a lease. After granting lease to client if a change occurs on the file on the server then the server may send a lease break to client indicating that data should be flushed from the cache.
In some scenarios, a client may have same lease key for different connections to the same server accessing the same file. If the server sends a lease break addressed to the (Lease Key, Client GUID) tuple, and if more than one connection from the client has the same lease key, only the first connection from the client to the server may be given the lease break notification.
This brings problems when a proxy on the data path between the client and server caches data that serves multiple other clients who are all are asking for the same file. With such a lease scenario as explained above, only one connection from client to server will get the lease break. The remaining clients may be left in the dark about the lease break notification due to reasons such as process restarts occurring during the connection or other disruptive services. If the proxy service misses the lease break notification, the related file may be left in an inconsistent state. There exists a need to address this and other problems with coherency management in SMB to ensure that all client/server connections are aware of the lease break notification.